feat(bcode-serve): serve-only binary variant for headless containers - #148

The V4 worker spends most of its cold startup waiting for `bcode serve` to
become ready: `worker.bcode.listen` is ~1.50s p50 in production, ~54% of the
measured worker cold path (ENG-5671).

Profiling the compiled binary shows the cost is spread across the whole server
import graph rather than concentrated in a few deferrable modules — whichever
of `provider`, `session/processor` or `tool/registry` is imported first pays
~200ms and the rest then cost ~0ms. So there is no cheap module to defer, and
restructuring 112 imports is not worth the merge friction against upstream.

Two levers that do work, applied together:

  - bytecode compilation: skips JS parse at boot, -33% spawn-to-listening
  - dropping the 23 unused command modules and the embedded web UI

The second matters mostly for size, and the two compound: excluding the unused
commands saves 16MB without bytecode but 81MB with it, since dead code also
carries compiled bytecode. Measured on darwin-arm64, medians of 7, no web UI:

  entrypoint         plain             bytecode
  opencode index.ts  108MB / 412ms     310MB / 266ms
  bcode-serve         92MB / 381ms     229MB / 257ms

On linux-arm64 (the container target) the variant is 257MB vs 148MB standard —
+110MB on a 744MB image, well inside AgentCore's 2GB cap.

This lives in its own package so `packages/opencode`, which is forked from
upstream and synced regularly, stays byte-for-byte untouched. Everything is
additive: the canonical build step still runs first and unmodified, the new
step is `continue-on-error` and writes different asset names, so it can never
block or clobber a normal release.

Cloud consumes the release asset through the install one-liner, so install.sh
gains `--variant serve`. `check_version` had to learn about it too — a variant
swap keeps the same version string, so the "already installed" short-circuit
would otherwise skip a standard -> serve switch.

The new build script duplicates the Bun.build config rather than editing the
upstream one; to catch drift its smoke test boots `serve` and waits for the
listening banner instead of just running `--version`, which a missing
build-time `define` would sail straight past.

…nstall.sh alone

Reverts the `--variant serve` flag added to install.sh in the previous commit
and ships a separate `install-bytecode.sh` instead, intended to be hosted at
bcode.sh/bytecode alongside (not replacing) bcode.sh/install.

install.sh is the published, documented entrypoint that the README and every
existing doc point at. Adding a flag to it meant every future change to the
variant touched the script humans install with. A second script and a second
URL keeps the blast radius at zero: nothing can change what /install serves.

The new script takes install.sh's flags, so switching is a one-word change to
the URL in a Dockerfile:

  curl -fsSL https://bcode.sh/bytecode | bash -s -- --no-modify-path --version $V

It is deliberately much shorter than install.sh: the variant ships one build
per arch (no baseline/AVX2 or musl detection), is linux-only, and targets
containers that set PATH in the Dockerfile (no shell-rc editing, no uv hint).
`--no-modify-path` is accepted as a no-op so an existing invocation works
verbatim.

Releases predating this variant do not publish the asset, so a missing asset
reports that explicitly rather than letting tar fail on a 404 body.

Note: the bcode.sh domain and its path routing are not configured in this repo
— only the scripts live here. Mapping /bytecode to this file has to happen
wherever /install is currently mapped.

Repo is public; internal ticket IDs don't belong in it. Benchmark figures
belonged in the PR discussion, not inline — they go stale and were restating
the rationale at length. Comments now say why something is the way it is and
stop there.

My previous fix validated the download by running `--version` from the temp
dir, which broke installs on hosts that mount /tmp noexec — common hardening,
and a regression: before that change the binary was only ever executed from the
install dir.

Stage inside the install dir instead. That keeps the safety property (a corrupt
or wrong-libc download can no longer replace a working bcode) without requiring
an exec-capable /tmp, since the install dir has to allow exec anyway. The final
step becomes a same-filesystem `mv`, so the swap is atomic and no reader can
observe a half-written binary. The staging file is cleaned up on every exit
path, and the failure message now names noexec on the install dir as a cause.

`Checkout` has no `ref:`, so on `workflow_dispatch` the tree is the dispatch ref
(usually main) while the upload still targets `inputs.tag`. Publishing from
there would put main's code inside that tag's assets.

The serve step now compares HEAD against the tag's commit and skips with a
visible warning when they differ, rather than uploading mislabelled binaries.
The warning matters because the step is continue-on-error and would otherwise
skip silently.

The canonical build step has the same exposure — this is pre-existing, not
introduced here, and fixing it properly means adding `ref:` to `Checkout` for
the whole job. That changes the standard release path, which this PR otherwise
leaves alone, so it belongs in its own change.